Why not a quick server-side patch. There is a shortcut that avoids any migration: setting schemaKey="Asset" inside strip_metadata stamps every stored asset without touching ASSET_COMPUTED_FIELDS or the constraint (strip_metadata runs on both asset write paths, and schemaKey stays a non-computed field, so a draft still has no computed keys). But it makes the server silently rewrite client-supplied metadata. dandi-archive already discards client-supplied computed fields in strip_metadata, yet that is at least explicit; hiding a schemaKey rewrite in the same place amplifies the "the client sends data the server quietly treats as wrong" smell, which is itself the argument for the formal validate-and-transform endpoint. So I'd rather not build further on the current design.

Done cleanly, it entails a migration. The natural way for the server to own schemaKey is to treat it as a computed field, i.e. add it to ASSET_COMPUTED_FIELDS so strip_metadata drops it from the stored (draft) metadata and full_metadata sets it to "Asset" on read. But ASSET_COMPUTED_FIELDS is baked into the asset_metadata_no_computed_keys_or_published CheckConstraint (a draft's metadata must contain none of those keys), so changing the list needs a RemoveConstraint/AddConstraint migration; and since every existing asset stores schemaKey today (it isn't stripped), every existing draft row would then violate the amended constraint, so a data migration must first strip schemaKey from all draft rows. Migration 0011_asset_access_metadata.py is the precedent: it rewrote every asset's metadata and re-created this same constraint for the access field.

The received BareAsset should be validated at the endpoint, and that is a separate check from validating the outcome. A BareAsset arriving at the endpoint should be validated server-side, synchronously at the point of receipt, against the Pydantic BareAsset model (or its JSON schema). That is distinct from validating the transformed outcome, the Asset (and, at publish, PublishedAsset). Today neither of those is true: ingestion is permissive and does no BareAsset validation, AssetRequestSerializer.metadata is a bare serializers.JSONField() whose validate() only checks blob/zarr exclusivity, that path is present and well-formed, and defaults schemaVersion; _create_asset stores the metadata after full_clean(validate_constraints=False); and the only dandischema check runs after storage, in an async task → validate_asset_metadata, which validates the outcome against PublishedAsset and merely records a VALID/INVALID status without rejecting the upload. So a proper design would add synchronous BareAsset validation at receipt, kept separate from that outcome validation.